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REMARKS 

Status of this application 

Claims 1-18 are pending. In the Office Action mailed on September 2, 2004, claims 3, 7, 
9, 12, 16 and 18 were rejected under 35 U.S.C. §1 12, 2 nd paragraph, for indefiniteness. Claims 
1-18 were rejected under 35 U.S.C. §103(a) as being directed to subject matter deemed obvious 
in view of the combined teachings of U.S. Patent 6,292,880 issued to Mattis et al. (hereinafter 
"Mattis") and U.S. Patent Application Publication No. 2002/0099734 filed by Schroeder et 
al. (hereinafter "Schroeder")* 

The Indefiniteness Rejection 

Claims 3, 7, 9, 12, 16 and 18 were rejected for indefiniteness because each claim recited 
means for, or the step of, accessing "zero or more selected ones" of the previously stored 
canonical messages, followed by a recitation of means for, or the step of, comparing an incoming 
message with said "selected ones/* As the Examiner noted, a comparison cannot occur if "zero" 
previously stored messages were accessed. Accordingly, claims 3, 7, 9, 12, 16 and 18 have been 
amended to delete "zero or more" from each rejected claim. It is believed that this amendment 
corrects the indefiniteness objected to by the Examiner. 

The Obviousness Rejection 

As pointed out by the Examiner in his rejection of claim 1 in Section 7 of the Office 
Action, Mattis discloses a cache which compares each incoming request message (the name or 
URL of a requested object) with previously received and stored request messages. Mattis does 
this by applying a hash function to the object's name as shown in Fig. 3B to form a name key. 
If a match is found between the resulting name key and a given previously stored name key (that 
is, if the newly formed name key is found in a directory table), then a stored response (the 
requested object) is retrieved from the cache and returned to the sender. 

As conceded by the Examiner, Mattis does not disclose converting the incoming request 
message into an incoming canonical request message expressed in a predete rmined standard 
form . The Examiner states, in Section 7 on page 4 of the Action, that "Schroeder discloses 
converting the incoming request message 404 into an incoming canonical request message" and 
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that it "would be obvious to a person of ordinary skill in the art at the time the invention was 
made to combine the teaching of Mattis with Schroeder to easily allow disparate systems using 
different protocols the ability to share information easily." 
Reconsideration is requested. 

First, Schroeder does not teach converting a "request message" into canonical Instead, 
Schroeder teaches a mechanism for transmitting the data content of documents between trading 
partners that use different data formats by first translating incoming data object into a standard 
(canonical) XML format, and then translating the data in standard format into an outgoing data 
object document having the format required by the system receiving the document. By 
translating incoming electronic business documents into an intermediate canonical format, only 
two translation processes are required for each participant, one for translating received 
documents from that participant into the canonical format, and another for translating outgoing 
documents from the intermediate canonical format into the format needed by that recipient. This 
eliminates the need for each participant to create and maintain a large number of different 
translation programs to exchange electronic documents with a large number of different systems. 

There is nothing in Schroeder's teaching that relates to caching, and nothing that suggests 
that the content of requests for data objects, or the names or URL that identify data objects, 
should be converted to canonical form. Schroeder instead converts data objects that are being 
exchanged into a canonical intermediate format to reduce the number of translation programs 
needed to allow many different systems to exchange data. 

The Examiner suggests that it **would be obvious to a person of ordinary skill in the art at 
the time the invention was made to combine the teaching of Mattis with Schroeder to easily 
allow to easily allow disparate systems using different protocols the ability to share information 
easily without the need for mandated data formats." 

Applicants submit that there is nothing in either reference that suggests that such a 
combination be attempted. Schroeder does not mention caching or teach ways to improve 
caching, and there is nothing in either reference that suggests that Schroeder' s methof for 
facilitating the exchange of data objects between data between different systems using different 
protocols could or should be used to improve Mattis* caching system. And even if there were 
some way in which Schroeder's canonical intermediate standard data format could be combined 
with a cache of the type taught by Mattis, one of ordinary skill would be attempt to convert the 
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data objects, and not the requests for the data objects, into a standard format in order to achieve 
the results which are the goal of the Schroeder data exchange system. 

It is accordingly requested that the rejection of claims 1-18 as being directed to subject 
matter deemed obvious in view of the combined teachings of Mattis and Schroeder be 
withdrawn. 

In additions, it should be noted that applicants' claims 2, 6-9, 1 1 , and 15-1 8 further 
specify that all or part of the request messages which are translated into canonical form are 
expressed in XML. As pointed out in applicants' specification, data requests expressed in XML 
may be logically identical but have different content; for example, logically identical XML 
request messages may have different line ending characters or include different whitespace 
characters which change the form but not the meaning of the request. Applicants' claimed 
technique of converting incoming XML requests into canonical form for storage and comparison 
allows logically identical requests to be identified, even though they don't have identical content 
as received. 

As the Examiner concedes in Section 8, Mattis does not disclose that a portion of the 
incoming request message be expressed in XML language or be translated into a standard 
canonical XML form. In fact, the caching system described by Mattis does not mention or deal 
with the special problems associated with caching XML requests and responses and indeed 
Mattis nowhere mentions using XML for any purpose. The Examiner further states, however, 
that "Schroeder discloses incoming request message is expressed in XML language and is 
translated into a standard canonical XML form (p. 2, IT 26-29). " It is submitted, as pointed out 
above, that Schroeder (including the cited passage in Schroeder) teaches only that data objects, 
not requests for or names of data objects, may be converted into an intermediate XML form 
during transmission. Schroeder neither recognizes nor addresses the problem that differences in 
the form of otherwise logically identical XML request messages complicates caching, and does 
not describe a solution to this or any other caching problem. Thus, for the reasons noted above, 
there is no suggestion in either reference that would lead one of ordinary skill to combine the two 
teachings, and even if such a combination were made, it would not result in a system in which 
requests for data objects, or the names of data objects, as opposed to the data objects themselves, 
would be converted to canonical form. 
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Because the cited references, taken singly or in combination, describe neither the 
difficulty of efficiently caching data when different requests for that data are logically identical 
but have different forms, and neither reference suggests the solution to that problem as claimed 
by applicants, the rejection based on obviousness should be withdrawn. 

Conclusion 

Reconsideration of this application and allowance of claims 1-18 as now presented is 
requested. 



Respectfully submitted, 
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